When a new network node is installed in a wireless communication network, it must be configured to fit within the network. In most instances, network nodes have some pre-configured information stored within their memories. When they are powered on during installation, they typically go through a start-up sequence. The start-up sequence is designed to take a new node from its initial powering up to being a fully functioning node within a network. The start-up sequence typically requires the new node to discover itself, its peers, its neighbors, its master, its location, its network, its attachment, and hundreds of other properties about itself and its environment well known to those of skill in the art.
After this discovery process, the new node ideally joins an existing network, which requires authentication. Authentication itself involves the new node providing information about itself including its state, its capabilities, its identifying data, knowledge exchange capabilities, its configuration, identifying information about its software, and so forth. Although many in the art follow these general principles, the incantations used to reach the desired result are widely varied in terms of node discovery, the protocols used, the roles of the various nodes and network entities and so forth. It is still the case that node configuration and start-up sequences are not optimized.
In the prior art, most of the configuration data for a node was entered at the manufacturing site according to information provided by the network operator controlling the network into which the node would ultimately be installed. When the operator installed the node, he or she added additional, site-specific configuration information. In this way, network nodes were largely preconfigured by node manufacturers. This method of configuring a new node is costly and requires precise tracking because, if a node preconfigured for a certain location ends up being installed at another location, the technician installing the node has to manually perform reconfiguration from scratch.
More recently, auto-configuration methods have reduced the amount of time required to configure new nodes. When an auto-configuration module is executed, it makes certain assumptions about the node to be configured and the network into which it is assimilating. First, it is assumed that the new node has a secure and dedicated connection to a next-hop neighbor. Second, nodes are either statically pre-configured for a particular location, or they have the ability to connect to a server that can facilitate configuration. When a node is pre-configured, it has most of the information that it needs to integrate into a network, but not all. Accordingly, the operational expenditure for installing the node can be high because experienced technicians have to install the node and complete the configuration process. In addition, pre-configured nodes are designed to be deployed at a particular location. If that location changes, the nodes must be reconfigured.
When a node obtains its configuration information by contacting a server, it uses, for example and without limitation, a dynamic host configuration protocol (“DHCP”) or a domain name server (“DNS”) or both to establishes a secure connection with an initial server, which could called “InitMaster.” If the node uses DNS, it performs a DNS query using a preconfigured IP domain for the server to obtain the IP address for the server. The secure connection could be made using IPSec or other well-known connection techniques.
After the node has established a secure connection, it provides its location and capability information, which may include information related to its hardware configuration, to the server. Having received this information, the server would determine whether it would serve the node or whether it should provide information sufficient for the node to establish a connection with another server, which could be called “ServMaster.”
From there, the node could again provide location and capability information to the ServMaster. The ServMaster could, in turn, provide the remaining configuration information needed for the node to integrate into the network. This remaining configuration information could be preset or dynamically generated. At this point, the node is configured and ready to operate within the network.
As previously stated, these auto-configuration processes are for wired nodes. Auto-configuration for wireless nodes is more complicated because the new node has to choose a next-hop node, which often means choosing from more than one potential next-hop node. Once it has chosen a next-hop node, it must establish a trusted connection between itself and that node before it tries to establish a connection with the InitServer. Ideally, wireless nodes would not be pre-configured in terms of the role they play within a network because that would allow them to be flexible and to adapt to network conditions in a real-time way. There is, therefore, a need to allow wireless nodes to utilize an auto-discovery mechanism that allows other network nodes to discover new nodes as they are powered on. When the new node is powered on, it can automatically be configured to join an existing network.